Many software products are built from a large number of source files that are usually written in a programming language that requires the compilation of the sources into a format that can be interpreted by computers efficiently. Often the software products are developed by large groups of software developers.
Software developers are usually equipped with computers that run integrated development environments (IDEs), such as Eclipse or Forte, to provide functionality for editing/modifying and compiling source files residing on the local hard drive of the developer's computer.
In order to allow cooperation in teams, source files are stored centrally and versioned using a source control mechanism (e.g., CVS) that contains the source files. A developer downloads source files from a source control system to his local computer, changes the source files and then stores the changed source files again in the source control system. A further developer can download the changed source files to his/her local computer by downloading them from the source control system.
To test changed source files, a developer can compile them on the local computer. To test interoperability with further source files that are changed by other developers, the developer has to compile the further changed source files as well.
Computing power of current computer hardware is insufficient to allow instant recompilation of large software products on a developer's local computer within an acceptable amount of time. Therefore, some IDEs, such as Eclipse, provide the ability to test changed source files of a software product by splitting the source files into smaller groups. These smaller groups can be compiled without a requirement to compile the software product as a whole. The smaller groups are typically referred to as projects or components. In the following description the term component is used.
Compilation and provision of distributable compilation results of the whole software product is typically performed by a central computer (e.g., a server computer). Typically, the central compilation is done after having transferred the source files of all components from the source control system to the central computer once a day, every few hours or in similar large time intervals. The central computer compiles all components and stores the compilation results. However, compiling all components even if no source files have been changed is a waste of resources of the central computer that might be usable otherwise.
Further, a developer always has to wait for the next central compilation before he/she can test the interoperability of the compilation result of a changed source file.
Further, the developer can transfer changed source files to the central computer that may cause errors in the central compilation although a previous local test compilation worked properly because of using outdated local copies of the compilation results of referenced components. If the central compilation fails each developer has to wait one more compilation interval before updating local copies of used compilation results (e.g., used libraries). If further changes of source files occur in the meantime, there is an increased probability that the central compilation fails due to these changes, because in many cases the changes have been tested against outdated libraries on local computers. This probability increases with the number of developers that work on the software product.
There is an ongoing need to reduce the number of central compilation failures.